Cryptographic encryption algorithms add confidentiality to sensitive data that is transmitted over an insecure channel. The data is protected, as the encryption algorithm transforms the data from plaintext into ciphertext prior to transmission. The recipient of the encrypted data is only able to decrypt the ciphertext and retrieve the plaintext from the received transmission if the recipient is able to reverse the encryption algorithm. If the encryption and decryption algorithms share the same key, the cryptosystem is known as “symmetric” and the algorithms are called symmetric-key algorithms. If the key in the encryption algorithm is different than the key in the decryption algorithm, the cryptosystem is known as “asymmetric” and the algorithms are called asymmetric-key algorithms.
In asymmetric-key algorithms, the key used for encryption (i.e. the “public key”) is publicly known, as everyone should be able to use it to encrypt sensitive data. However, the key used in the decryption (i.e. the “private key”) is only known to the intended receiver of the encrypted data and is protected such that the intended receiver is the only entity able to decrypt the encrypted message. An asymmetric cryptosystem is commonly referred to as a Public Key Cryptosystem (PKC).
In a PKC, the public key and the private key are independent of each other such that knowledge of the public key does not reveal or lead to the private key. In other words, the public key can be made public such that anyone can encrypt data for a specific recipient, but only the specific recipient has knowledge of the private key and is able to utilize the private key to decrypt and retrieve the data. Since the public keys in the PKC are publicly known, they are considered insensitive and can be transmitted over any insecure, public channel. However, the main challenge with the PKC is to trust whether an available public key is actually associated with the intended recipient. In other words, if a different public key (i.e. a wrong or modified public key) is used by mistake or by fraud, the overall security achieved by utilizing encryption is compromised. The security of the encryption in a Public Key Cryptosystem therefore relies on correctly distributing the public keys that belong to or are associated with the intended recipients of the encrypted message. Accordingly, it is necessary to verify the public keys before encrypting sensitive data with a public key in a PKC.
Since large systems are dynamic and new members join or leave the system at all times, public keys are constantly issued and/or revoked. At the time of registration (setup), a new member is assigned a new set of public/private keys and all the other existing members are notified of the new public key before they can securely communicate with the new member, using the new public key generated.
In the PKC, there are two mechanisms for generating and distributing the public keys throughout the system. In the first mechanism, the public keys are generated by a trusted center, which would then distribute them remotely over a secure channel to the users in the system. The second mechanism is for a sender to generate the public key locally for every recipient. In this way, the trusted center is not required to first generate a private key for every recipient and then distribute these generated public keys remotely over a secure channel to every sender.
Generating public keys locally is superior to relying on a trusted center to provide the public keys. When the public encryption keys are generated locally, the latency of encryption is reduced in that it is no longer necessary to retrieve a certificate from a remote server.
Traditionally in the PKC, public keys are generated by a trusted center (certificate authority) guaranteeing that a public key belongs to a certain recipient. The certificate authority is a trustworthy entity that distributes the certificates throughout the PKC. In a typical PKC, the trusted center is operable to produce an X.509 certificate that includes the public key for a recipient as well as other ancillary data. The trusted center then digitally signs the provided certificate, in order for the sender to verify the authenticity of the provided certificate and the corresponding public key. Nevertheless, distributing and managing the public key certificates in a large system is a challenging task, as the certificates have to be protected from tampering over insecure channels during transmission or when received at the sender's local machine.
An alternate approach to public key encryption is to self-generate the public parameters that would be used to encrypt sensitive data using the recipient's known identity, such as a phone number, email address or username. Boneh and Franklin have introduced an Identity-Based Encryption (IBE®) scheme in which the identity of the recipient is used in the encryption, such as described in Dan Boneh and Matthew Franklin, “Identity-Based Encryption from the Weil Pairing” SIAM Journal of Computing, 32(3):586-615, 2003 and U.S. Pat. No. 7,113,594, the contents of which are hereby incorporated by reference in their entirety. In their setup, every user is given a private key, but the encryption key is constructed using the identity of the recipient and the trusted center's public key. Their system removes the need to contact the trusted center (certificate authority) to retrieve the public key of a recipient. However in their system, the public key of the trusted center (Ppub) has to be strictly protected. If a different public key is used in the encryption by mistake or fraud, the security of the encryption is entirely compromised.
It should be noted that the entire security of their scheme relies on the security of the public key of the trusted center, which is publicly known and therefore widely available. If an adversary can change the public parameter(s) of the trusted center either by accessing the local storage of trusted center's public key or by sending a different public key via a man-in-the-middle attack, the security of the encryption system is compromised.